Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

Data types and cache types

To understand the caching capabilities of the framework, let’s start with some common definitions. First, here’s a way of categorizing your data to assess its suitability for caching. Categories of data include:

System data and administration data — This is the read-only data that defines your application, such as entities and user preferences. In Dynamics, any caching of this information is handled by the Repository and the framework. This type of data and caching is not covered here. See the chapters on Dynamics managers for more information.
Nontransactional data — Application data that can change on the client. When it does, it is unlikely to affect other data records (for example, records holding descriptive information). This information is a good candidate for Dynamics caching if it meets the following criteria:
It is infrequently modified.
It is frequently accessed.
There is a low volume of the data.
Loading this data into the cache at application startup does not degrade start-up performance below your required benchmarks.
Note: Although the framework caching support makes a somewhat suitable SDO for handling genuinely static data, there are simpler solutions. For example, true constant data, such as a list of weekdays or a list of months, can be defined in widget or object attributes, global variables, external files, hard-coded source and so on. This approach avoids AppServer hits completely.

Transactional data — Data that results from application transactions. Transactional data which is application data found on the client, is not well suited for caching because:
It has high volume.
It might be child data.
It might be frequently modified.

All these reasons mean that the data will change frequently, force frequent updates of the cache, become a performance drain, and thereby defeat the purpose of client-side caching.

There are many types of caching schemes, each with its uses, include:

Persistent cache — Data can be stored on the client side persistently and will be accessible at the client side from session to session. Progress Dynamics does not support persistent caching with SDO-based application data caching. There are cache APIs that will make it easier for you to develop your own persistent caching scheme. See the "Cache APIs" section for an overview of the available hooks.
Session cache — All data in the cache is destroyed when the session ends. When a new session starts, data needed again is retrieved from the server. The framework cache for client-side application data is a session cache.
Timed cache — Cached data is only valid for a specific time and must be flushed after this time. Either a persistent cache or a session cache can be a timed cache. In Dynamics, you can configure the session cache to be a timed cache or a cache that lasts the entire session.
Note: Framework caching or application data is a run time feature. Since no application caching is done in development mode, you’ll need to test your caching schemes during run time.